---
title: "Utilities"
description: "Helper scripts: disk wipe for thin‑pool prep and high‑density stress testing"
---

This guide explains how to use the helper scripts under `utils/`.

## Wipe a disk for thin‑pool provisioning

Script: `utils/wipe-disk.sh`

<Warning>
Destructive operation. This irreversibly erases all partitions, RAID metadata, filesystems, and attempts discards on the target device. Double‑check the device path.
</Warning>

### Usage

```bash
sudo ./utils/wipe-disk.sh /dev/nvme2n1
```

You will be prompted to type `YES` to proceed. The script will:

- Remove filesystem signatures (`wipefs -a`)
- Zap the partition table (`sgdisk --zap-all`)
- Zero the beginning and end of the disk (`dd`)
- Attempt block discard (`blkdiscard`) if supported

List disks to find the correct device:

```bash
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
```

Requirements: Linux with `wipefs`, `sgdisk`, and `blkdiscard`; run as root or via `sudo`.

## High‑density CPU/memory stress test

Script: `utils/stress_test.sh`

This script launches many sandboxes to validate CPU limit enforcement and observe resource behavior.

### What it does

- Creates namespace `stress-test`
- Generates `k7-stress-*.yaml` files, each with:
  - `before_script` that installs `stress-ng` and `htop` via `apk`
  - CPU and memory limits per sandbox
- Launches sandboxes in batches (default 50 total, batches of 10)
- Sets up a cleanup trap on Ctrl+C to delete resources and namespace

Default parameters (edit inside the script if desired):

- `COUNT=50`
- `NAMESPACE="stress-test"`
- `CPU_LIMIT="300m"`
- `MEM_LIMIT="2Gi"`
- `STRESS_MEM="1500M"`

### Run

```bash
bash utils/stress_test.sh
```

Monitor during the test:

```bash
k7 top -n stress-test
watch 'k3s kubectl top pods -n stress-test --sort-by=cpu'
```

Cleanup when done (also done automatically on Ctrl+C):

```bash
k7 delete-all -n stress-test -y
rm k7-stress-*.yaml
k3s kubectl delete namespace stress-test
```

Notes:

- The generated YAML uses Alpine and installs packages in `before_script`. Ensure the container can run `apk` (i.e., not forced non‑root during setup). If you enforce strict non‑root, consider prebuilding an image with dependencies.
- Ensure your node(s) have sufficient CPU/RAM to handle the configured load.


